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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is part of a series of documents specifying charging functionahty and charging management in 
GSM/UMTS networks. The GSM/UMTS core network charging architecture and principles are specified in 
3GPP TS 32.240 [1] which provides an umbrella for other charging management documents that specify: 

• the content of the CDRs per domain and subsystem (offline charging); 

• the content of real-time charging messages per domain / subsystem (online charging); 

• the functionality of online and offline charging for those domains and subsystems; 

• the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or 
charging events). 

The complete document structure for these TSs is defined in 3GPP TS 32.240 [1]. 

The present document specifies the mechanisms used to transfer the CDRs from the network to the operator's billing 
domain (e.g. the billing system or a mediation device). This includes the file transfer procedures and the layout of the 
CDR files, as well as file meta information and the encoding of the CDRs within the files. 

The CDR types that can be transported in these files are specified in the respective domain / subsystem / service 
charging TSs, i.e. 3GPP TS 32.250 [10] - 3GPP TS 32.297. A definition of the parameters, abstract syntax and encoding 
rules for these CDR types are specified in 3GPP TS 32.298 [51]. 

Note that the present document, dealing with CDRs, is consequently only concerned with offline charging. A definition 
of 3GPP online charging functionality and applications can be found in 3GPP TS 32.299 [50] for the network side, and 
3GPP TS 32.296 [53] for the billing domain side. 

All references, abbreviations, definitions, descriptions, principles and requirements, used in the present document, that 
are common across 3GPP TSs, are defined in the 3GPP Vocabulary, 3GPP TR 21.905[100]. Those that are common 
across charging management in GSM/UMTS domains or subsystems are provided in the umbrella document 
3GPP TS 32.240 [1] and are copied into clause 3 of the present document for ease of reading. Finally, those items that 
are specific to the present document are defined exclusively in the present document 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

a) The 3GPP charging specifications 

[I] 3GPP TS 32.240: "Telecommunication management; Charging management; Charging 
architecture and principles". 

[2]-[9] Void. 

[10] 3GPP TS 32.250: "Telecommunication management; Charging management; Circuit Switched 

(CS) domain charging". 

[II] 3GPP TS 32.251: "Telecommunication management; Charging management; Charging data 
description for the Packet Switched (PS) domain". 
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[12] 3GPP TS 32.252: "Telecommunication management; Charging management; Wireless Local Area 

Network (WLAN) charging". 

[13]-[19] Void. 

[20] 3GPP TS 32.260: "Telecommunication management; Charging management; IP Multimedia 

Subsystem (IMS) charging". 

[21]-[29] Void. 

[30] 3GPP TS 32.270: "Telecommunication management; Charging management; Multimedia 

Messaging Service (MMS) charging". 

[31] 3GPPTS 32.271: "Telecommunication management; Charging management; Location Services 

(LCS) charging". 

[32] -[49] Void. 

[50] 3GPP TS 32.299: "Telecommunication management; Charging management; Diameter charging 

application". 

[51] 3GPP TS 32.298: "Telecommunication management; Charging management; Charging Data 

Record (CDR) encoding rules description". 

[52] Void. 

[53] 3GPP TS 32.296: "Telecommunication management; Charging management; Online Charging 

System (OCS) applications and interfaces". 

[54] 3GPP TS 32.295: "Telecommunication management; Charging management; Charging Data 

Record (CDR) transfer". 

[55]-[69] Void. 

b) other charging specifications 

[70] ITU-T Recommendation D.93: "Charging and accounting in the international land mobile 

telephone service (provided via cellular radio systems)". 

[71]-[99] Void. 

c) Common 3GPP specifications 

[100] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[101] 3GPP TS 22.101: "Service aspects; Service principles". 

[102] 3GPP TS 22.1 15 "Service aspects; Charging and bilUng". 

[103] 3GPP TS 23.002: "Network architecture". 

[104] 3GPP TS 23.003: "Numbering, addressing and identification". 

[105] 3GPP TS 27.001: "General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS)". 

[106]-[199] Void. 

d) other Domain and Service specific 3GPP / ETSI specifications 
[200]-[299] Void 

e) Relevant ITU Recommendations 
[300]-[399] Void. 

f) Relevant IETF RFCs 

[400] IETF RFC 959 (1985): "File Transfer Protocol". 
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[401]-[499] Void. 

g) Network Management related specifications 

[500] 3GPP TS 32.341: "Telecommunication management; File Transfer (FT) Integration Reference 

Point (IRP): Requirements". 

[501] 3GPP TS 32.342: "Telecommunication management; File Transfer (FT) Integration Reference 

Point (IRP): Information Service (IS)". 

[502] 3GPP TS 32.343: "Telecommunication management; File Transfer (FT) Integration Reference 

Point (IRP): Common Object Request Broker Architecture (CORE A) Solution Set (SS)". 

[503] 3GPP TS 32.344: "Telecommunication management; File Transfer (FT) Integration Reference 

Point (IRP): Common Management Information Protocol (CMIP) Solution Set (SS)". 



3 Definitions, abbreviations and symbols 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 32.240 [1] and the following 
apply: 

Billing Domain (BD): part of the operator network, which is outside the core network, that receives and processes 

charging information from the core network charging functions 

It includes functions that can provide billing mediation and billing end applications. 

charging function: entity inside the core network domain, subsystem or service that is involved in charging for that 
domain, subsystem or service 

CDR field Categories: defined in the present document. They are divided into the following categories: 

• Mandatory: field that shall be present in the CDR. 

• Conditional: field that shall be present in a CDR if certain conditions are met. 

• Operator Provisionable: Mandatory: A field that operators have provisioned to be included in the CDR for all 
conditions. 

• Operator Provisionable: Conditional: A field that operators have provisioned to be included in the CDR if 
certain conditions are met. 

charging: function whereby information related to a chargeable event is formatted and transferred in order to make it 
possible to determine usage for which the charged party may be billed 

Charging Data Record (CDR): record generated by a network element for the purpose of billing a subscriber for the 
provided service 

It includes fields identifying the user, the session and the network elements as well as information on the network 
resources and services used to support a subscriber session. In the traditional circuit domain, CDR has been used to 
denote "Call Detail Record", which is subsumed by "Charging Data Record" hereafter. 

circuit switched domain: domain within UMTS in which information is transferred in circuit mode 
domain: part of a communication network that provides services using a certain technology 

GPRS: Packet Services for GSM and UMTS systems 
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middle tier (charging) TS: used for the 3GPP charging TSs that specify the domain / subsystem / service specific, 

onUne and offline, charging functionality 

These are all the TSs in the numbering range from 3GPP TS 32.250 [10] to 3GPP TS 32.271 [31], 

e.g. 3GPP TS 32.250 [10] for the CS domain, or 3GPP TS 32.270 [30] for the MMS service. Currently, there is only 

one "tier 1" TS in 3GPP, which is TS 32.240 [1] that specifies the charging architecture and principles. Finally, there are 

a number of top tier TSs in the 32.29x numbering range ([50] ff) that specify common charging aspects such as 

parameter definitions, encoding rules, the common BD interface or common charging applications. 

near real time: near real time charging and billing information is to be generated, processed, and transported to a 
desired conclusion in less than 1 minute 

offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered 

online charging: charging mechanism where charging information can affect, in real-time, the service rendered and 
therefore a direct interaction of the charging mechanism with session/service control is required 

packet switched domain: domain within GSM and UMTS in which data is transferred in packet switched mode. 
Corresponds to the term "GPRS" 

real time: real time charging and billing information is to be generated, processed, and transported to a desired 
conclusion in less than 1 second 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3G 3"^'^ Generation 

BD Billing Domain 

CDF Charging Data Function 

CDR Charging Data Record 

CGF Charging Gateway Function 

CS Circuit Switched 

CTF Charging Trigger Function 

FTP File Transfer Protocol 

GMLC Gateway MLC 

IMS IP Multimedia Subsystem 

MLC Mobile Location Center 

MMS Multimedia Messaging Service 

OAM&P Operation, Administration, Maintenance and Provisioning 

OCS Online Charging System 

PS Packet Switched 

UTC Universal Time Coordinated 

WLAN Wireless Local Area Network 

3.3 Symbols 

For the purposes of the present document, the following symbols apply: 

Be Reference point for the CDR file transfer from the Circuit Switched CGF to the BD. 

Bi Reference point for the CDR file transfer from the IMS CGF to the BD. 

Bl Reference point for the CDR file transfer from the GMLC CGF to the BD. 

Bp Reference point for the CDR file transfer from the Packet Switched domain, i.e. the GPRS CGF, to 

the BD. 

Bm Reference point for the CDR file transfer from the MMS CGF to the BD. 

Bw Reference point for the CDR file transfer from the WLAN CGF to the BD. 

Bx The reference point between any (generic) 3G domain, subsystem or service CGF and the BD. 

Rf Offline Charging Reference Point between the CTF within a 3G network entity and the CDF. 
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Architecture considerations 



"Bx" is a common designator of the interfaces from the network to the bilHng domain (BD) that are intended for the 
transport of CDR files. The letter x indicates the different 3GPP network domain, subsystem or service, where 

c represents Circuit Switched (CS), 

p represents Packet Switched (PS), 

i represents IP Multimedia Subsystem (IMS), 

1 represents Location Service, 

m represents Multimedia Messaging Service (MMS), 

o represents the Online Charging System (OCS) and 

w represents Wireless LAN (WLAN). 

By definition, dealing with CDR files only implies that Bx is solely related to offline charging. The following figure 
depicts the position of the Bx reference point within the overall 3GPP offline charging architecture. 
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CTF: Charging Trigger Function 

CDF: Charging Data Function 

CGF: Charging Gateway Function 

BD: Billing Domain. This may also be a billing system/ billing mediation device. 

Figure 4.1 : Logical ubiquitous offline charging architecture 

As illustrated in the above figure, the CGF in each network domain, service or subsystem is relevant for the network 
side of the Bx interface. On the billing domain side, by its nature of dealing with CDRs, Bx addresses only the offline 
charging part. Further details of this part of the Billing Domain are outside the scope of 3GPP standardization. Refer to 
3GPP TS 32.240 [1] for the complete description of the 3GPP charging architecture. 
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5 CDR File Transfer Principles and Scenarios 

This clause contains specifications for the principles and scenarios covering the CDR file transfer interface from the 
network to the Billing Domain. These specifications apply to all domains, subsystems and services listed in clause 4. 
Alternatively, in the CS domain (i.e. for Be), the file transfer mechanism specified in 3GPP TS 32.250 [10] may be 
used. Consequently, for Be it is up to implementation choice to provide either the legacy interface, the interface 
specified in the present document, or both. 

The principles and scenarios in this clause are divided into the following categories: 

• Local CDR and CDR file handhng; 

• File format; 

• File Transport and protocol; 

• File transport modes and session management. 

Other interface principles such as security and performance are dependent on vendor implementation and operator's 
network design and are not covered by the present document. 

5.1 Local CDR and CDR file handling 



5.1.1 CDR processing 



As depicted in figure 4.1. above, the CGF collects CDRs from the CDF. If the CDF and the CGF are separate entities, 
then the standard Ga interface as specified in 3GPP TS 32.295 [54] is used. If CDF and CGF are integrated, then a 
proprietary mechanism is used to transfer the CDRs from the CDF to the CGF. The possibilities of separate or 
integrated CDF and CGF are specified per domain, subsystem and service in the respective "middle tier" charging TS, 
e.g. in 3GPP TS 32.250 [10] for the CS domain, 3GPP TS 32.251 [11] for the PS domain, etc. The references clause of 
the present document lists all the related reference TSs in the 3GPP TS 32.250 [10] through [49] reference number 
range. 

In any case, CDRs are transferred, in near real time, from the CDF to the CGF as soon as they have been closed by the 
CDF. Refer to 3GPP TS 32.295 [54] for further details. Once received by the CGF, the CDRs may undergo semantical 
and/or syntactical sanity checks before storing them on the file, however, these are not further specified within the 
present document. 

If the CGF determines that a CDR is not well formatted, or otherwise incorrect, then the defective CDR parameter(s) 
shall be filled with an appropriate "replacement" indicator within the limits of the syntax allowed for the parameter. If 
the error renders the complete CDR unusable (i.e. the above replacement of erroneous parameters is not possible), then 
further action of the CGF is ffs. An example of a case where the erroneous parameter cannot be replaced is when the 
"CDR type" attribute of a CDR received by the CGF is corrupted. Details of this function are implementation specific. 

CDRs that have been processed by the CGF without error, or where errors have been corrected by the CGF as described 
above, are considered "acceptable" by the CGF. CDRs that have non-recoverable errors are not considered "acceptable" 
by the CGF. The "acceptable" CDRs are immediately placed into a CDR file by the CGF. The CDRs that are not 
"acceptable" should be properly reflected in an error log and appropriate alarms should be generated, after which they 
may be destroyed. 

It is acknowledged that the processing of a CDR between being received until it is placed on the CDR file, will take a 
small amount of time. Hence, where the present document mandates the "immediate" treatment of CDRs received by 
the CGF, it is to be interpreted such that it is not allowed to postpone the processing of any received CDRs for any 
reason. In technical terms, "immediate" shall be interpreted as 

• The system shall be capable of complying with near real time requirements as specified in subclause 3.1. 

• The system should be capable of complying, as closely as possible, with real time requirements as specified in 
subclause 3.1. 
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Once a CDR has been stored on the appropriate file, the CGF may destroy any other reference to that CDR. 



5.1.2 CDR routing 



In the default mode of operation, the CGF manages a single ("default") file for the storage of all "acceptable" CDRs. 
However, the CGF may also route CDRs to different files that are kept open concurrently, i.e. additional files may be 
configured by OAM&P commands together with associated CDR routing filters. While the CGF will store only those 
CDRs matching the associated routing filter on each of the additional files, the default file is used to store all CDRs that 
do not match any of the routing filters configured for the additional files. 

The CDR routing function shall apply CDR parameters and CDR origin to decide into which file to place the CDR. The 
file name shall, within the limits of the file naming conventions, contain an indication of the CDR routing filter applied. 

As a minimum, each CGF implementation shall support the CDR type and the sending CDF as a selection criteria for 
CDR routing. It shall then be possible to include in a file only the following CDRs: 

• CDRs of a single type; 

• CDRs of a set of specified types (e.g. only IMS CDR types); 

• CDRs originated by a single CDF; 

• CDRs originated by a set of CDFs; 

• Any combination of the above. 

Further details of the CDR routing function, such as 

• the maximum number of simultaneously open CDR files; 

• the order in which the routing filters are evaluated; 

• the way CDR filters can be configured by OAM&P; 

are implementation specific. In order to avoid arbitrary routing of CDRs, operators should assure that the routing filters 
assigned per file, do not overlap with each other. 

The term "matching CDR" is used in the present document to denote a CDR that matches the routing criteria of a given 
CDR file. 

5.1 .3 Local CDR file management 

For the default case, plus each of the additional CDR routing criteria that may be set up on the CGF (cf. subclause 5.1.2 
above), the CGF provides a non-interrupted chain of CDR files. As described above, each CDR is immediately stored in 
the appropriate file after being received and determined "acceptable" by the CGF. 

Several conditions may govern the closure of a CDR file by the CGF: 

• A configurable file size limit; 

• A configurable file closure time; 

• A configurable file lifetime ("interval"); 

• A configurable number of CDRs within the file; 

• CDR release, version or encoding change; 

• Manual OAM&P actions; 

• System defined reasons (e.g. file system full). 

When a CDR file is closed, the next matching CDR shall be placed in the next file in the chain. The exact time when 
this next CDR file is physically generated, i.e.: 
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• immediately after the previous file has been closed (i.e. the earliest possible time), 

• when the next matching CDR arrives (i.e. the latest possible time), 

• anytime in between, 

is implementation specific. For example a CDR file may reside in temporary, internal storage while collecting CDRs, 
until it is triggered to close. However, the CDRs contained in the file are all "acceptable" matching CDRs received and 
processed by the CGF between the closure of the previous file and the configured file closure trigger of the current file, 
as specified above. In any case, a file must be generated and closed upon the occurrence of the file closure trigger, 
i.e. an empty file (containing no CDRs) if no matching CDRs arrived since the closure of the last file in the chain. Upon 
file closure, the CDR file is immediately available for transfer to the BD. 

CDR files may be removed from the CGF in one of the following ways: 

• By the BD issueing corresponding commands provided by the file transfer protocol; 

• By the CGF application once the file has been transferred; 

• Due to CGF file system storage limitation or configurable file age limits; 

• OAM&P action. 

In order to avoid loss of CDRs, Operators should manage the system in a way that the "system defined" file closure 
triggers mentioned above do not occur. 

5.2 File format principles 

The CDR file format is depicted below. 



r 



Concatenated CDRs 
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Header with Specified Length 




CDR1 


CDR 2 


CDR 3 
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CDRS 
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Figure 5.2.1 : CDR File Format 

The CDR files contain a variable length header section followed by a variable sized CDR data section. The CDR data 
section contains zero or more concatenated CDRs. All CDRs in a file are of the same data record format, release, 
version and encoding scheme. 

The latest version of a CDR that is contained in the file should be identified in the file header. The BD should use a 
decoder with a version number which is equal or greater of this version to be able to decode all the CDRs in the file. 
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5.3 Protocols for charging data files transfer 

a) The default protocol for CDR file transport is FTP (RFC 959 [400]). 

b) The use of other protocols is optional, however FTP must always be supported. 

c) The CDR files may be transferred in either push or pull mode on the Bx interface. Further specifications of these 
transfer modes are provided in subclause 5.4.1 and subclause 5.4.2, respectively. 

d) All standard FTP commands specified in RFC 959 [400] shall be supported by the CGF. 

All further requirements specified within the present document with reference to the operation of the file transfer 
protocol (cf. clause 6), are solely related to FTP as the transfer protocol, as no assumptions can be made as to the ways 
of working of the optional other protocols. However, additional protocols shall be implemented such that, to the extent 
possible, the same logic is applied as described in the present document for FTP. 

5.4 File transport modes and session management 

Files can be transferred to the BD in one, or both, of the following modes. Detailed FTP file transfer and session 
management procedures are specified in clause 6. 

5.4.1 Push mode 

In this transfer mode the CDR files are written from the CGF to the BD filestore at a time and/or frequency controlled 
by the CGF. I.e. The CGF pushes the files to the BD. This implies that the CGF operates in client mode and the BD in 
server mode. If the CGF generates concurrent CDR files based on the CDR routing function specified in 
subclause 5.1.2, then it shall be able to send the different files to different BD systems, i.e. the BD address is part of the 
CDR routing filter. 

As a minimum, the following events shall be capable of triggering a file push in the CGF: 

• A (configured number of) new CDR file(s) has become available for transmission; 

• The CDR file / files has / have exceeded a configurable (total) size limit; 

• A configurable, regular time interval has elapsed; 

• The CGF filestore utilization has exceeded a configurable level. 

If the file transfer fails, the CGF should properly reflect this in an error log and generate appropriate alarms. Possible 
measures to handle file transfer failures are discussed in clause 6. 

Security measures, e.g. the mutual identification / verification of the peer systems, are outside the scope of the present 
document. 

5.4.2 Pull mode 

In this transfer mode the BD reads the CDR files that are available in the appropriate CGF directories. The time and/or 
frequency of the file transfer is controlled by the BD. I.e. the BD pulls the files from the CGF. This implies that the 
CGF operates in server mode and the BD in client mode. 

In this mode, the BD may request the files from the CGF at any point in time at the discretion of the BD, i.e. the CGF 
cannot make any assumptions of the time or frequency of the file pull to occur. If the file transfer fails, any further 
action is up to the BD, however, the CGF should properly reflect this in an error log and generate appropriate alarms. 
Possible measures to handle file transfer failures are discussed in clause 6. 

Security measures, e.g. the mutual identification / verification of the peer systems, are outside the scope of the present 
document. 
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CDR file format specification 



This clause provides detail specifications for the CDR file format. These specifications apply to all domains, 
subsystems and services listed in clause 4. Alternatively, in the CS domain (i.e. for Be), the file transfer mechanism 
specified in 3GPP TS 32.250 [10] may be used. Consequently, for Be it is up to implementation choice to provide either 
the legacy interface, the interface specified in the present document, or both. 

The file format specification in this clause is divided into the following categories: 

• File format conventions; 

• File naming and directory conventions; 

• Detailed FTP file transfer and session management procedures. 

• Error handling 

6.1 File format conventions 

a) The CDR files contain a variable length file header immediately followed by a variable number of concatenated 
CDRs which are encoded according to the CDR format specified in an appropriate charging TS, 
3GPPTS32.250[10]to[49]. 

b) All the CDRs in the file are encoded in the appropriate Abstract Syntax Notation One (ASN.l) and encoding 
rules as specified in the appropriate 3GPP TS 32.298 [51]. 

c) All the CDRs in the file are encoded with the same encoding release and they should be decoded with a single 
version of a decoder. 

d) The file header are in Network byte order (Big Endian). 

e) The Header contains fields specifying the length of the header and the length of the file in total. 

f) Fields in the header that are not known at the time the file is opened should be populated after all the CDRs are 
included and the file is ready to be closed. 

The CDR file is named based on a naming convention specified in clause 6.2. 

6.1 .1 File header format 

The file header contains the following fields: 

• Total file length in octets - including the length field itself. 

• File Header length in octets - the fixed length of the file header plus the length of the Private Extension (if 
present). 

• Data Record format as defined in 3GPP TS 32.298 [51]. 

• Application & Release identifiers as defined in 3GPP TS 32.298 [51]. 

• CDR Version as defined in 3GPP TS 32.298 [5 1 ] . 

• The UTC timestamp when the file was created. 

• The UTC timestamp when the last CDR was appended to the file - set to zero if the file contains no CDRs. 

• Number of data records in the file. 

• File Sequence Number. This field includes a unique number created by this node. The number is allocated 
sequentially for each CDR file. The number is unique within a node. It should match the sequence number used 
in the file name (If present). 
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• File Closure reason (see subclause 6.3.1). 

• Length of the IP Address of the file generating node. For IPv6 the value is decimal 20. For IPv4 the value is 
decimal 4. 

• IP address of the network node that generated the file. Fixed length field of 20 octets. For IPv4 addresses, the 
unused trailing octets are set to zero. 

• Length of the Private extensions field. Set to zero (0) if no private extensions are present. 

• CDR routing / filtering indication. 

• Private extension (Optional). 

The exact format of the CDR file header is given below. 



Bits 


Octets 


8|7|6|5|4|3| 2 |1 


1..4 


File length in octets (including file header and CDR payload length) 


5..8 


Header length in bytes (Octets 1 to 53 and the length of any private extensions) 


9* 


Data Record Format 


10* 


Application ID Release ID 


11* 


CDR Version 


12.. 15 


File opening timestamp (UTC) 


16.. 19 


Timestamp when last CDR was appended to file (UTC) (Zero if the file contains no CDRs) 


20. .23 


Number of data records in file 


24..27 


File sequence number 


28 


File Closure Trigger Reason (See below) 


29 


Length of IP Address of Node that generated file 


30..49 


IP Address of Node that generated file (20 octets, padded for IPv4) 


50..53 


Length of Private Extension field 


54. .xy 


CDR routing filter 


xy..n 


Private Extensions (optional) 



NOTE: Fields indicated with an asterisk (*) are the same formats and contain the same ranges of values as those 
defined in 3GPP TS 32.240 [1] and 3GPP TS 32.298 [51]. 

Figure 2: Format of CDR File Header (Shaded area represents the fixed part of the file header) 

6.1.2 Encoding of file header fields 
6.1 .2.1 File Closure Trigger Reason 

The file closure reason provides a means to determine the reason that the file was closed by the CGF. It is encoded as a 
single octet as follows. 

Normal closure reasons (Decimal values to 127): 

= Normal closure (Undefined normal closure reason). 

1 = File size limit reached (OA&M configured). 

2 = File open-time limit reached (OA&M configured). 

3 = Maximum number of data records in file limit reached (OA&M configured). 

4 = File closed by manual intervention. 

5 = Data record format, release or version change. 

6 to 127 are reserved for future use. 

Abnormal closure reasons (Decimal values 128 to 255): 

128 = Abnormal file closure (Undefined error closure reason). 
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129 = File system error. 

130 = File system storage exhausted. 
131= File integrity error. 

132 to 255 are reserved for future use. 

6.2 CDR file naming convention 

The file naming convention ensures that CDR file names are unique amoung a large number of CGF nodes over an 
extended period of time (At least several months). In order to accomplish this requirement, the file name should include 
the following information: 

• Generating Node identifier (alpha- numeric characters); 

• Locally generated file Sequence number; 

• Timestamp indicating the time that the file was closed; 

• CDR routing indication; 

• Optional private information; 

• Optional file extension. 

The exact format of the CDR file name is ffs. 

The default directory structure on the CGF for the storage of CDR files is ffs. 

6.3 Detailed FTP transfer and session management procedures 

• FTP client. 

• FTP server role. 

• File transfer triggers. 

• Each in relation to push and pull modes. 

6.4 Error handling 

Replacement of invalid CDR parameters 
Handling irrecoverable CDRs 
System dependent failures (file system full, etc.) 
File transfer failure 

• Pull mode 

• Push mode 



£75/ 



3GPP TS 32.297 version 6.0.0 Release 6 



17 



ETSI TS 132 297 V6.0.0 (2004-03) 



Annex A (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


Jun 2003 


S 20 


SP-030273 


-- 


-- 


Submitted to TSG SA#20 for Information 


1.0.0 




Mar 2004 


S 23 


SP-040142 


-- 


-- 


Submitted to TSG SA#23 for Approval 


2.0.0 


6.0.0 



















































































£75/ 



3GPP TS 32.297 version 6.0.0 Release 6 



18 



ETSI TS 132 297 V6.0.0 (2004-03) 



History 



Document history 


V6.0.0 


March 2004 


Publication 



























£75/ 



